SSL/SSH inspection

> Chapter 9 - Firewall > Security policies > SSL/SSH Inspection

SSL/SSH inspection

While the profile configuration for this is not found in the Security Profiles section but in the Policy Section, it is set in the policy along with the security profiles. This sort of analysis is some times referred to as deep scanning.

Deep Inspection works along the following lines. If your FortiGate unit has the correct chipset it will be able to scan SSL encrypted traffic in the same way that regular traffic can be scanned. The FortiGate firewall will essentially receive the traffic on behalf of the client and open up the encrypted traffic. Once it is finished it re-encrypts the traffic and sends it on to its intended recipient. It is very similar to a man-in-the-middle attack. By enabling this feature, it allows the FortiGate firewall to filter on traffic that is using the SSL encrypted protocol.

The encrypted protocols that can be inspected are:

HTTPS
SMTPS
POP3S
IMAPS
FTPS

Before the invention of SSL inspection, scanning regular web traffic can be circumvented by using the prefix https:// instead of http:// in the URL. SSL inspection prevents this circumvention. However, because when the encrypted traffic is decrypted it has to be re-encrypted with the FortiGate’s certificate rather than the original certificate it can cause errors because the name on the certificate does not match the name on the web site.

At one point deep inspection was something that was either turned on or off. Now individual deep inspection profiles can be created depending on the requirements of the policy. Depending on the Inspection Profile, you can:

Configure which CA certificate will be used to decrypt the SSL encrypted traffic.
Configure which SSL protocols will be inspected.
Configure which ports will be associated with which SSL protocols for the purpose of inspection.
Configure which websites will be exempt from SSL inspection
Configure whether or not to allow invalid SSL certificates.
Configure whether or not SSH traffic will be inspected.

HTTP Strict Transport Security (HSTS) Protocol

HSTS is a protocol used by Google and other web browsers to prevent man-in-the-middle attacks.

When performing deep inspection, the FortiGate intercepts the https traffic and would send its own self-signed CA certificate to the browser. If the browser is configured to use HSTS connections, it would refuse the FortiGate CA certificate since it is not on the trusted list for Google servers.

To keep the CA certificate from being refused, the HSTS settings should be cleared from the browser. Instructions for this vary between browsers.

Inspection exemption

When you are using a browser to visit SSL encrypted sites and we are using a certificate that does not match the certificate of the site, we are presented with a warning message and the option of continuing, using the untrusted certificate, or terminating the session. However, there are a number of applications that use SSL encrypted traffic. If the application detects SSL traffic that wasn't signed with a certificate that it trusts it will not allow the traffic. The applications do not give the option to manually indicate that we trust the certificate or the site.

If the option is available, the customer may choose to import needed SSL certificates into Local Certificates and configure a policy for communication for that application.

The assist in preventing loss of access to these site but still enabling the SSL inspection of the rest of the internet traffic, a method of exempting either Website categories or specific sites has been developed. To exempt a large group of sites the profile can be configure to exempt FortiGuard Categories. There are 3 of these categories preselected due to the high likelihood of issues with associated applications with the type of websites included in these categories.

Heath and Wellness
Personal Privacy
Finance and Banking

Other more specific websites can be added to the exemption list by creating addresses for them at Policy & Objects > Objects > Addresses. The adding of addresses is done by selection from a drop down menu. There is an option at the bottom of the list to create a new address, but otherwise only preconfigured addresses that are configured to be on the "Any" interface will be available for selection.

Examples of sites that you may want to configure for exemption so that there will be no interference due to certificate issues:

Apple

*.appstore.com
*.apple.com
*.itunes.apple.com
*.icloud.com
swscan.apple.com

Dropbox

*.dropbox.com

Skype

*.messenger.live.com

Windows Updates

update.microsoft.com

Allow invalid SSL certificate

This setting was something that used to be part of the Proxy Options, but now that SSL inspection has it’s own configuration setting it is configured with those. It might seem like a straight forward decision that the allowing of invalid SSL certificates must be bad and therefore should not be allowed, but there can be some reasons that should be considered. The issues at hand are the reasons to use a SSL certificate and the reasons that a certificate will be considered invalid.

At a purely technical level, a properly formed certificate will encrypt the data so that it can only be read by the intended parties and not be read by anyone sniffing traffic on the network. For this reason, people will often use self-signed certificates. These self signed certificates are free and will encrypt the data just as well as those purchased from any of the big vendors of certificates, but if they are not listed as an approved Certificate Authority (CA) the certificates will be considered invalid.

On the other hand, one of the services the vendors provide is verification of identity of those that purchase their certificates. This means that if you see a valid certificate from a site that identified itself as being from “valid-company.com” that you can be reasonably sure that the site does belong to that company and not a false site masquerading as being part of that company.

Creating or editing an SSL/SSH inspection profile

Go to Policy & Objects > Policy > SSL/SSH Inspection.
This will open to one of the existing profiles.
The links for the actions are located in the upper right hand corner of the window.

To view a list of the exiting profiles select the List icon (a page) at the far right.
To clone an existing profile, select the Clone icon (one page behind another), second from the right
To create a new profile, select the Create New icon ("+ "symbol), third from the right.
To view or edit an existing profile, choose it from the dropdown menu field.

Name Field:
Give the Profile an easily identifiable name that references its intent.
Comments Field:
Enter any additional information that might be needed by administrators, as a reminder of the profile's purpose and scope.
SSL Inspection Options:

Enable SSL Inspection of:

Multiple Clients Connecting to Multiple Servers - Use this option for generic policies where the destination is unknown.
Protecting SSL Server - Use this option when setting up a profile customized for a specific SSL server with a specific certificate.

CA Certificate
Use the drop down menu to choose which one of the installed certificates to use for the inspection of the packets.
Inspection Method
The options here are:

SSL Certificate Inspection - only inspects the certificate, not the contents of the traffic.
Full SSL Inspection - inspects all of the traffic.

Inspect All Ports
Enable the ability to inspect all ports by checking the box. If the feature is not enabled, specify in the field next to the listed protocols, the port through which that protocols traffic will be inspected. Traffic of that protocol going through any other port will not be inspected.

Exempt from SSL Inspection:
Use the dropdown menus in this section to specify either a FortiGuard Web Category or addresses that will be exempt from SSL inspection.

Web Categories
By default the categories of Health and Wellness, Personal Privacy, and Finance and Banking have been added as these are one that are most likely to have applications that will require a specific certificate.
Addresses
These can be any of the Address objects that have an interface of "Any".

SSH Inspection Options:

SSH Deep Scan
Toggle the grey on button so that it is:
Greyed out to disable the feature
Opaque and vibrate to enable the feature
SSH Port
The available options are:

Any - choosing this option will search all of the traffic regardless of service or TCP/IP port for packets that conform to the SSH protocol
Specify - choosing this option will restrict the search for SSH protocol packets to the TCP/IP port number specified in the field. This is not as comprehensive but it is easier on the performance of the firewall.

Protocol Actions

Exec - Block, Log or neither. Select using check boxes.
Port-Forward - Block, Log or neither. Select using check boxes.
SSH-Shell - Block, Log or neither. Select using check boxes.
X11-Filter - Block, Log or neither. Select using check boxes.

Common Options:

Allow Invalid SSL Certificates
Check the box to enable the passing of traffic with invalid certificate
Log Invalid Certificates
Check the box to have the Logging function record traffic sessions that contained invalid certificates

The Enable SSH Deep Scan feature is enabled by default when creating a new SSL/SSH Inspection profile. There are situations were this feature can cause issues so be sure that you would like it enabled before applying it.

The context location for configuring the SSL/SSH Inspection in the CLI is:

config firewall ssl-ssh-profile

Viewing firewall policies

When you first go into the Policy window, found by going to Policy > Policy > Policy, you will see a table with a menu bar across the top. The menu bar will have the following items:

At the top left:

Create New (with a “+” sign on the left and a downward pointing triangle on the right)
Clone
Delete
Column Settings
Filter Settings

At the top right:

Section View
Global View

The items at the top right with their radio buttons represent the 2 potential views that the policies can be displayed in.

The Global View shows all of the policies in the order of their sequence. With the default settings you will be able to see the sequence number in a column close to the left side of the table.

The Section view is similar to the Global View except that as the name implies it is divided into sections. By default the sections are based on the paths between the interfaces. These can be referred to as “interface pairings”. For instance, all of the policies referencing traffic from WAN1 to DMZ will be in one section. The policies referencing traffic from DMZ to WAN1 will be in another section.

The sections are collapsible so that you only need to look at the sections with policies you are interested in. It is possible to add customized subsections within the default sections of interface pairings. This would be useful in a situation where you have a lot of policies and would like to further compartmentalize them by common attributes so that things are easier to find.

The default column headings are:

[Check box icon]
Seq.#
Source
Destination
Authentication
Schedule
Service
Action
Log

The column that are shown are configurable. All but the first 2 can be removed or their position changed. There are also a number of other columns that display information about the policies that can be added. One of the more useful ones that can be added is the ID column. The reason for adding this one is that policies are referenced by their ID number for simplicity and ease of administration. If you are looking in the CLI you will see that the only designation for a policy is its number and if you wish to change the order of a policy you will be asked to move it before or after another policy by referencing its number.

How “Any” policy can remove the section view

The FortiGate unit will automatically change the view on the policy list page to Global View whenever a policy containing “any” in the Source interface/zone or Destination interface/zone is created. If the Section View is greyed out it is likely that one or more of the policies has “any” as a Source or Destination interface.

With the use of the “any” the policy should go into multiple sections because it could effectively be any of a number of interface pairings. As mentioned, policies are sectioned by using the interface pairings (for example, port1 -> port2) and each section has its own specific policy order. The order in which a policy is checked for matching criteria to a packet’s information is based solely on the position of the policy within its section or within the entire list of policies as a whole but if the policy is in multiple sections at the same time there is no mechanism for placing the policy in a proper order within all of those sections at the same time because it is a manual process and there is no parameter to compare the precedence of one section or policy over the other. Thus a conflict is created. In order to resolve the conflict the FortiGate firewall removes that aspect of the sections so that there is no need to compare and find precedence between the sections and it therefore has only the Global View to work with.

Security policy configuration extensions

When first creating the policy the configuration form will ask for a choice between the policy types of Firewall or VPN, Firewall being the default. Choosing whether or not to leave the selection as Firewall is straight forward. If the policy is not a policy based VPN policy then it is a Firewall policy type.

There are essentially 2 types of VPN connections, Interface Based and Policy Based. In an Interface Based VPN tunnel a logical interface is created that can be seen as an interface by the policies in the same way that any of the physical interfaces can be seen. Therefore to govern the traffic a regular policy will work. The policy based VPN tunnels work slightly different and therefore need a slightly different policy configuration. For a more detail explanation of the difference between the types of VPN tunnels refer to the VPN documentation found in the VPN handbooks or in the VPN section of the Complete Administration Guide.

Once either the Firewall or the VPN type has been chosen there is then a choice between one of subtypes for each of the Policy types. For the Firewall type of policy the subtypes are:

Address
User Identity
Device Identity

The Address subtype refers to policies where access through the FortiGate firewall is dependant on the source location of the addresses of the devices involved in the traffic matched to the policy.

The User Identity subtype refers to policies where access through the FortiGate firewall is dependant on the users credentials or Identity.

The Device Identity subtype refers to policy where access through the FortiGate firewall is dependant on the specific device being used based on the MAC address of the device or belonging to a group of devices that are based on device types or belonging to custom made groups.

For the VPN type the subtypes are:

IPsec
SSL-VPN

As expected the two subtypes are the two different types of VPN tunnels that the FortiGate firewall supports in a policy based configuration.